home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13350 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.0 KB  |  91 lines
  1. Newsgroups: comp.lang.c++,comp.lang.eiffel,comp.lang.c,comp.object,comp.software-eng
  2. Path: assip.csasyd!news
  3. From: donh@syd.csa.com.au (Don Harrison)
  4. Subject: Re: Portability of code & skills (Beware of "C" Hackers etc)
  5. Message-ID: <Dot383.45s@assip.csasyd.oz>
  6. Sender: news@assip.csasyd.oz
  7. Reply-To: donh@syd.csa.com.au
  8. Organization: CSC Australia
  9. References: <31517E6F.5930@dmu.ac.uk>
  10. Date: Mon, 25 Mar 1996 04:31:14 GMT
  11.  
  12. Graham Perkins wrote:
  13.  
  14. :Don Harrison wrote:
  15. :> :adoption of C and Unix.
  16. :> 
  17. :> Aside from the historical argument, could another reason be that people
  18. :> love power and permissive languages such as C give such power?
  19. :
  20. :Permissive, yes.  Power?  I don't think so.  Perhaps too many people 
  21. :confuse the two.  For example, local functions give a certain power,
  22. :expecially if you can pass them as parameter as in Pascal.  This power
  23. :is unavailable in C.  Simple manipulation of structured objects is
  24. :quite awkward, and has been severely limited and error prone for most
  25. :of the lifetime of the C language.  Cobol's pattern matched input and
  26. :pattern editing output is extremely powerful, but C does not even check
  27. :you pass the same number of print items as you specify, never mind give
  28. :you the power to control currency sign, leading zero suppression, decimal
  29. :format, credit/debit formats... And what about that file handling?
  30. :Read an arbitrary number of bytes into an un-typed buffer .. that's power?
  31. :
  32. :No curried functions, function constructors, lazy evaluation, or generic
  33. :data and function types.  No assertions, exceptions, concurrency, or
  34. :parallelism.  No built in string, vector, matrix, or complex operations.
  35. :No garbage collection.  No embedded SQL.  No opaque types or language
  36. :construct for naming a group of related operations.  Think of any powerful
  37. :construct you like from any language and you will find it NOT in C (or
  38. :at least not during the period C was catching on).
  39.  
  40. I was thinking of 'power' in terms of having the freedom to do what you want.
  41. I should have said 'freedom' or 'permissiveness'. If you define 'power' as 'the
  42. ability to say little and acheive much', C's nature, as you indicated, is the 
  43. antithesis of it. 
  44.  
  45. :> :..universal assembler ..does not seem to have happened, and I don't understand
  46. :> :why.
  47. :> 
  48. :> Someone else already pointed out that Eiffel uses it as such.
  49. :
  50. :Well it hasn't really happened in the way I meant.  Those who demand their
  51. :systems in C are resistant to Eiffel because they perceive it as a language
  52. :that is not C, in spite of the C back-end.
  53.  
  54. If they perceive it that way, then they are right because Eiffel is very much 
  55. a language in it's own right. The fact that is compiles into C is incidental.
  56. It could (and, IMO, *should*) compile into a better 'universal assembly language'
  57. than C. What would the characteristics of such a language be?
  58.  
  59.   - maps as directly as possible onto the hardware (for efficiency, portabilty)
  60.   - inheritance/polymorphism (can a new generation of OO hardware remove/reduce 
  61.     the performance penalty of dispatching?)
  62.   - ??? (fill in the gaps).
  63.  
  64. [...]
  65.  
  66. :It seems to be a matter of flavour.  If the Eiffel browsers worked almost
  67. :entirely visually (eg, class tool contains rename table, redefinitions
  68. :colour coded, export control by dropping classes into or pulling out of
  69. :a viewpoint icon) then much of the syntax could disappear or be hidden.
  70. :Then people would be more inclined to view it as an OO development system 
  71. :for C rather than as a different language.
  72.  
  73. These sound like good ideas. However, IMO, Eiffel is not a tool that would be 
  74. readily marketed to the C community because their focus is different. Eiffel has 
  75. too high an emphasis on quality and reliability to appeal to most C users ;-).
  76. It would be more attractive to those who actually practice real software 
  77. engineering (rather than paying lip service to it).
  78.  
  79. :-- 
  80. :person: Graham Perkins         paper: School of Computing
  81. :voice:  +44 (0)1908 834936            De Montfort University
  82. :dots:   +44 (0)1908 834948            Milton Keynes MK7 6HP
  83. :bits:   grp@dmu.ac.uk                 United Kingdom
  84.  
  85. Don.
  86.  
  87.  
  88.  
  89.  
  90.  
  91.